IBIS Macromodel Task Group Meeting date: 15 September 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad said he wanted to discuss an editorial issue he found in the IBIS 6.1 spec. (see below in New Discussions) - Walter said that now that 6.1 was approved, we ought to start discussing the rewrite of the discussions of "ground" in the spec. - Arpad took Walter's suggestion as a motion to untable item #9. - Radek seconded the motion, and none were opposed. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to draft a new version of the Info, Out, InOut BIRD and send it out. - Done. - Mike Labonte to finalize and post Todd's minutes from September 1st. - Done. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections for the minutes from September first? [none] - Arpad: Motion to approve the minutes. - Curtis: Second. - Arpad: Anyone opposed? [none] - Arpad: Does anyone have any comments or corrections for the minutes from September eighth? [none] - Mike L: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Editorial Issue with IBIS 6.1 spec. - Discussion: Arpad had noticed that the 6.1 spec had a section 10.3 "AMI Parameter Definition File Structure" and then 10.4 "Reserved Parameters For Data Management". However, the "General Reserved Parameters" section (heading at the bottom of page 202) was not included in the table of contents and did not have its own section number (presumably, it should be 10.4 and subsequent sections' numbers incremented). Everyone agreed that Arpad had found a legitimate issue. Since it had existed prior to 6.1, everyone agreed that it was okay to simply fix the issue in the next revision of the spec. Mike L. agreed to be the gatekeeper of the "ver6_1_known_issues.txt" file and to add this issue to it. Item #6: Info, Out, InOut BIRD draft. - Arpad: [sharing his new BIRD draft on the screen] - I have significantly rewritten the Statement of Issue and Analysis Path sections based on our recent discussions and changes in the spec itself over the past few years [this BIRD had been dormant for a while]. - New Reserved parameter VendorSpecificParams [name change - see below] - Not required. - Illegal in version 6.1 or before. - Direction: Rx, Tx. - Format: Value, List [changed to Table - see below] - Discussion: Parameter name. - Walter said that he preferred a different name for the parameter. Arpad said that he wanted the name to clearly relay the message that some of these parameters may not be handled by all tools. Some liked the suggestion of "pre-standard," but others thought it too presumptive. Ultimately the group settled on "non-standard". - Discussion: Parameter Format. - Bob R. had stated that he preferred a simple Boolean parameter. Walter had agreed that it would be sufficient. Others preferred a Table listing all of the non-standard parameters. Todd said that reducing it to a Boolean could cause the model user to panic, but not tell them what the issues were. Radek and John preferred the parseable list of names provided by the Table, as opposed to free form text in a description field. Ultimately, Bob R. said he was okay with the Table parameter concept. - Arpad: Based on these discussions, I think my BIRD draft is close. - Ambrish: Can we say "[non-standard parameters] must be listed" when we have no way to enforce it via the parser? - Is there precedent for any other spec providing a way to undermine itself? - Todd: I understand your point, but I think we're acknowledging the speed of of the industry not undermining the spec. - Ambrish: If someone unfamiliar with these discussions opens the spec, they see a description that opens the door to legitimizing these non-standard parameters. - Todd: The goal is to shine a spotlight on such parameters for the user. - If something's not portable tell me what it is, what it does, and what is the workaround. - Arpad: We could take an enforceable heavy-handed approach that would only allow parameters that are standardized and portable. - But then we'd be saying that to do anything new you have to take it outside of IBIS altogether. - That might have the opposite effect of what we want. It might encourage people to go further outside the spec and not ever come back. - Ambrish: What is the incentive for the model maker to draw this to a close? - What is the incentive to get the new parameters accepted into the standard? - Is there a strong incentive? - Arpad: The incentive for the model maker is provided by their customer base. - If their customers want to use all different types of tools, then that provides the incentive. - Bob R: One concern is it's stated in the spec but not enforceable which parameters must be listed. Should all In/Out params be listed? - Bob M: The issue is any non-standard tool-model interactions. - Radek: Correct, this parameter is used if such behavior exists. - We already have noted in the spec that InOut or Out parameters in the Model Specific section are only to be passed to the user. Other tool usages of Info, In, Out, InOut should be required to be listed in this new parameter table. - Bob R: I'm not sure there's any way to check if something should have been included in the list and isn't. - Bob M: I don't think you can parse a model and figure out if a tool is interacting in a non-standard way. - What about the possibility that an EDA tool and a model might interact in a way that doesn't involve a parameter? - I think we want to make every such interaction tied to a parameter, even if it's a dummy parameter, so that it can be listed in the table. - We should have a parameter associated with every silent handshake agreement. - Walter: We have that issue now with redriver flow. - The current spec has a well-known error in the redriver flow description. - Unfortunately, the ATM has been unable to agree on the wording of a revised flow to fix the issue. - So we [SiSoft] have a private agreement with certain model makers that we are going to do the redriver flow the right way. If other tools use the spec flow they will get different answers. - Arpad: In that situation I'd think we should have a dummy Info parameter. - Todd: An Info parameter that says what type of processing you expect. - Radek/Walter: Agreed. - Discussion: Listing all non-standard parameters. - Bob M. suggested that to avoid clutter we might only list one non-standard parameter associated with each feature. For example, for PAM4 there were multiple non-standard parameters developed and only one might need to be added to this list. Bob R. and John said that not listing all of them would cause more confusion. Radek agreed and said clutter was not a problem. Language corrections related to "ground" [untabled earlier, see above]: - Walter: [sharing his document from a June ATM meeting presentation] - I think we unanimously agreed that 6.2 should say that C_comp is connected to the buffer local ground. - I think someplace in IBIS we need a statement that says any reference to ground connections in an I/O buffer is really a connection to the pd_ref or gc_ref terminal for that buffer. - Radek: I think of it the other way around. I think we should describe how the pd_ref or gc_ref is connected to the ground. - Walter: I would like Radek to work on the wording of this statement. - I think if we can agree on this wording then 99% of the job is done. - Arpad: Thank you all for joining. AR: Mike L. to add a ver6_1_known_issues.txt to the 6.1 spec folder and add the issue Arpad discovered ("General Reserved Parameters" section number). AR: Radek to propose ground connection language. ------------- Next meeting: 22 September 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives